Finally some language-level improvements?
It would not be unfair to characterize the last few Delphi releases as All Mobile, All The Time. And as cool as that is for mobile developers, those of us still working in VCL land have sort of felt like we’re getting the short end of the stick. The last time anything significant was added to the core language itself was extended RTTI in Delphi 2010 (plus extended RTTI support for array properties XE2.) So I have to admit, I was excited when my boss sent this Google+ post around to the developers this morning.
It’s from an XE7 preview, and apparently the new focus is Parallel, now that the major Mobile bases are covered. Asynchronous and parallel for loop support at the RTL level (though apparently not at the language level like Oxygene provides) looks interesting… though I have to wonder. Isn’t everyone interested in stuff like that already using OTL anyway? The slide about the System.Threading library looks like someone borrowed a bunch of concepts from .NET (again), but without the language-level async support that makes it so simple to use in C# or Oxygene. (Seriously, read those articles about async in .NET if you haven’t already seen them. Eric Lippert does an excellent job of explaining why language-level support is necessary in order to both do it right and at the same time preserve developers’ sanity. I suppose it could be implemented as a macro in Boo, but that requires an open compiler before you can even start down that path…)
But the thing that really interests me is the last slide from the post, where it mentions improved support for arrays and array initialization, and better Generics support. Could it be that Embarcadero is finally adding proper Generics collapsing and improved constant array initialization, like I’ve been wanting for years? That second one may not seem like much, but it can make a huge difference in maintainability when working with a codebase under active development!
Well, let’s hope so at least…
FWIW Intrinsic type helpers were the last language feature also affecting VCL developers.
And about OTL: that one is Windows only while the new System.Threading will be cross platform.
Hmm… what’s new with that? We use XE4 at work, and we’ve already got helpers on a bunch of intrinsic types: integer, string, floating point types, etc. Or is this something different?
I was commenting on your “The last time anything significant was added to the core language itself was extended RTTI in Delphi 2010”. They are not that big of an improvement as RTTI or generics were (because they are just syntax sugar) but still nothing to forget about.
Oh, I see. I misread that. Thought you meant you’d seen the presentation and that’s one new thing they were adding. 😛
You have a point there.
Another point is that it is much easier to implement this on a back-end that already has a solid foundation for new stuff like parallel computing (llvm). I do not doubt there is much to follow.
It is also a bit cheap to sell it as features.
If they mirrored .NET’s TPL (or part of it) – that’s great! This is long term missing built-in feature in Delphi! 🙂
But it’s rather complex functionality. I would expect many bugs at the beginning…
I’m interested how WaitAny() method is realized in a cross-platform manner (:
Waiting to see it!
Let’s hope for some compiler speed improvements like using all MMX instruction sets when available. I can remember, once in a while they ask a strange question “What’s best for Delphi small exe or fast speed ?” DAMMIT ! They should have the answer allready ! When they choose the DFM system they implicitly answered the question themselves : The exe are allready big ! Now stop asking and make them fast ! Who want’s a slow exe anyway ? What a funny question, LOL.
I mean, i’m not a compiler specialist, but a freepascal exe is faster with floating points and I have read it’s because it makes better usage of MMX / SSE. This should not be. Delphi speed was allways the #1 feature, Embarcadero must go and catch the speed crown again, there’s no question about that. Marketing wise saying “I’m fast” is better than saying “I’m small”. And mobile ? well they’ll get memory before speed and “640k should be enought for everyone anyways” LOL
@wchris The 64 bit compiler uses SSE for FP, that being the hardware fp unit on x64. So if you want that perf, use the 64 bit compiler.
Thanks for the info. Since the rumors say Windows 9 will not support 32 bits… the 64 bit compiler is indeed a serious option in the future.
What rumors would those be? Because that would be downright suicidal on Microsoft’s part…
It’s too early to tell, at this point we are just guessing. I think it would mean windows 9 would only be available in 64 bits flavor, but could still be able run 32 bits apps.
But who knows … msft likes suicide itself remember : windows vista (full of bugs), windows 7 (no upgrade path from XP without vista), windows RT (full incompatible), windows 8 (incompatible with mouse), to be continued …
replace “windows vista (full of bugs)” by “windows vista (incompatible with drivers)”, full of bugs is just the consequence not the “feature” 😉
a 64 bits OS can run 32 bit apps, but a 32 bit OS cannot run 64 bits apps. So if we get rid of 32 bit os with windows 9 then 64 bits app becomes the standard de facto, that’s what I meant.
That would mean newer 7 inch tablets like the Dell Venue 8 Pro wouldn’t get the update. It is 32 bit Windows 8.
The Dell Venue 8 pro is powered by an intel® Atom™ Z3740D which is 64bits capable. And Msft always provided an upgrade path from previous -1 OS versions. But we don’t know full system requirement for windows 9 yet, so it’s too early to be sure.